Computerized devices control almost every aspect of our life—from writing documents to controlling traffic lights. However, computerized devices are bug-prone, and thus require a testing phase in which the bugs should be discovered. The testing phase is considered one of the most difficult tasks in designing a computerized device. The cost of not discovering a bug may be enormous, as the consequences of the bug may be disastrous. For example, a bug may cause the injury of a person relying on the designated behavior of the computerized device. Additionally, a bug in hardware or firmware may be expensive to fix, as patching it requires call-back of the computerized device. Hence, many developers of computerized devices invest a substantial portion of the development cycle to discover erroneous behaviors of the computerized device.
During the development cycle of a circuit, the functionality of the circuit may be analyzed using functional verification. Functional verification may be performed using a simulator, such as HDL simulator, which provides a software simulation of the behavior of the circuit. Additionally or alternatively, an acceleration platform, also referred to as an “accelerator” or a “hardware accelerator”, may be utilized to perform functional verification, The accelerator is a hardware-based simulator of the circuit design, such as using Application-Specific Integrated Circuit (ASIC), Field Programmable Gate Array (FPGA), or the like.
As accelerator is implemented in hardware it is much faster than a simulator. On the downside, there is a reduced visibility to the value of each signal in the circuit design during the simulated execution by the accelerator with respect to a simulator.
Instruction-by-Instruction (IBI) checking is a method of checking that a circuit design behaves correctly at the architectural level during simulation. An IBI checker operates during simulation and typically checks three things: (1) Instructions are completed in program order; (2) Register that are expected to be updated, are indeed updated with their expected values; and (3) Registers that are not expected to be updated, are indeed not updated.